-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cache finalised attributes to avoid conversion overhead every usage #282
Conversation
try | ||
{ | ||
if (dbAttribs.Length == 0) | ||
return difficultyAttributes; | ||
|
||
return difficultyAttributes; | ||
difficultyAttributes = LegacyRulesetHelper.CreateDifficultyAttributes(ruleset.RulesetInfo.OnlineID); | ||
difficultyAttributes.FromDatabaseAttributes(dbAttribs.ToDictionary(a => (int)a.attrib_id, a => (double)a.value), beatmap); | ||
return difficultyAttributes; | ||
} | ||
finally | ||
{ | ||
attributeCache[key] = difficultyAttributes; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe all of this works but it's intricate enough to be pushing my limits of how much subtlety I'm willing to accept in code, what with all of the juggling of difficultyAttributes
, implicit null returns of TryGetValue()
, and finally
used to coalesce return paths in order to populate attributeCache
...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, this is the standard way I'd write any caching code (I believe it's done this was elsewhere) but I'm neutral to approaching it differently. Would be be more understandable if the early return did the null-caching inline?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The general pattern is standard yes, I'm more talking about the mechanics here.
Would be be more understandable if the early return did the null-caching inline?
To a degree, but it would also make it mechanically uglier, so I decided I would just put up with this as is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One thing to keep in mind is that this will cache attributes even if they fail, and then they will pass as if nothing went wrong the next time around. There's two places that can fail - either the attributes are not present in the DB which I can't immediately think of a situation in which it should be allowed (and it previously returned null
too), or the deserialisation fails which is always a bad sign.
Exercise is left up to the reader to determine what this means for scores computed using the "actually failed but cached" attribs.
No description provided.